It seems CI is failing because I missed to update the CMake files. I might have some time to fix that in the following days, but if anybody familiar with CMake wants to help It would be great. I think it is only needed for the new GimbalController class.

Thanks @Davidsastresas. Sounds like we should do a v4.4.1 release soon.

Great to see this!

of course I'll help with testing and if we want to do that 4.4.1 release then I'll help organise that like last time

I suppose we don't need QGeoTiledMapReplyQGC::setIgnoreSSLErrorsIfNeeded in Qt6 since it already uses OpenSSL3, but it doesn't hurt to have it either

I suppose we don't need QGeoTiledMapReplyQGC::setIgnoreSSLErrorsIfNeeded in Qt6 since it already uses OpenSSL3, but it doesn't hurt to have it either

Good catch! At first I thought the same, but then I realized it is useful too for the other way around, for Qt6 in systems that have OpenSSL1 instead. I think it doesn't hurt either, so I would vote for leaving it there. Thanks for the review!

@Davidsastresas Fixed CMake

@Davidsastresas Fixed CMake

Amazing, thank you very much! Let's give it a few days in case Julian and Randy come up with some modification needed before merging. I will remove the draft label too. Thank you!

I tried to test this today on my Windows machine and it wouldn't even start. I used the installer found here.

I suspect that the issue is not actually related to this PR so I tried to install the "Daily Build" but was not able to find an installer. The link on the Daily Builds page seems broken (click here to see what I mean)

Sorry to hear that @rmackay9, if you had your previous build environment setup for QGC 4.4, for master you need qt6, and I am not sure if for windows you need different visual studio toolchain too. There are lots of changes on the build setup right now for QGC 4.4 vs master.

The builds corresponding to this PR should be here ( I found them searching manually in actions ):
Linux: https://github.com/mavlink/qgroundcontrol/actions/runs/10068063218
macos: https://github.com/mavlink/qgroundcontrol/actions/runs/10068063221
windows: https://github.com/mavlink/qgroundcontrol/actions/runs/10068063226
android: https://github.com/mavlink/qgroundcontrol/actions/runs/10068063231

Let me know if that fixes the situation for the moment!

EDIT - I see you used the build I recommended above, sorry I don't know why I thought you were trying to build from source. How was it not even starting, did it report something or any kind of error popup? @HTRamsey, do you know if master is supposed to be working fine in windows? Thanks!

Oh you'll have to try again on the latest build because of this #11678, it works fine now.

Hi @HTRamsey,

Is there a link to a Windows installer for latest? I can't find one that works (see my comment above).

I wonder if this PR should be rebased on master to pickup PR 11678?

You can always just grab it from the latest run. But yeah I guess the daily windows link needs to be updated.

Also @Davidsastresas you said you found those links manually from actions, if I'm understanding you correctly just FYI you can also just click details on the builds results below where it says All checks have passed.

Capitals shouldn't matter in a URL but I noticed the installer has an upper case 'i' while the link & docs have it as lower case. Could that be why the download isn't working?

Hi @HTRamsey @Davidsastresas,

Thanks for that. So the daily build using this installer does work and I think this means that this PR does not but hopefully that is just because it needs to be rebased (I'm guessing of course)

@Davidsastresas a followup to my QGeoMapReplyQGC comment, you can just use QGCFileDownload::setIgnoreSSLErrorsIfNeeded which is the exact same function.

Also @Davidsastresas you said you found those links manually from actions, if I'm understanding you correctly just FYI you can also just click details on the builds results below where it says All checks have passed.

@HTRamsey For some reason doing that I can only see the job, but not the artifact to download! Does it work for you to download the artifact too? I am using google chrome in case that matters.

Thanks for fixing build for Windows. I haven't had the chance to build because I need to setup cmake, I was still using qmake, it is probably not a big deal but I need to spare an hour or two to understand everything for the next time.

I rebased to master. @rmackay9 after it finishes it should be ready for you to test. Thanks!

setIgnoreSSLErrorsIfNeeded

@HTRamsey Please note the branch is in mavlink repo, so you can directly push commits to it. Please feel free to change that if you see fit. As it is now it works for me on a machine with OpenSSL 1 on Ubuntu 20.04. Thanks!

@julianoes for awareness, I just pushed here your commits from this PR #11706 So hopefully we can keep master updated with what we are doing in QGC 4. Thanks!

@Davidsastresas after clicking details you have to click Summary at the top left

@Davidsastresas after clicking details you have to click Summary at the top left

No way.... I've been for ages thinking it was a github bug. Thank you for enlightening me! :)

I tested this today on my windows PC and it seems to work fine with some issues found which I think are also in QGC Daily.

I connected my desktop CubeRed + SiyiA8 to my PC via USB and confirmed the following worked

1. gimbal control menu appeared (but only after having connected with MP or manually setting the SR0_xxx parameters)
2. "Center and "Tilt 90" buttons worked
3. Yaw Lock / Yaw Follow worked correctly. In particular when in Yaw Lock, the gimbal maintained its heading regardless of the autopilot's heading. In Yaw Follow the gimbal's yaw rotated with the vehicle
4. Click-to-point on the video stream resulted in the gimbal pointing to a reasonable angle (I did not have the FOV set perfectly but it seemed correct)
5. "Point Home" and "Retract" buttons worked

By the way, not related directly to this testing but this gave me the opportunity to test the camera controls (FYI @DonLakeFlyer):

• The zoom slider worked!
• The take-picture button did not work sadly
• The record video control was not visible

Also not related to this PR but it seems that QGC Daily is not proactively requesting data from the autopilot. It seems to be passively waiting for the drone to start sending mavlink messages. This seems like a change in behaviour vs QGC4.4. I guess it is intentional? BTW, I think that AP obeys the mavlink spec and we've documented here on this AP wiki page how GCSs, companion computers can request data be sent by the autopilot which includes three basic methods:

1. Using SRx Parameters
2. Using REQUEST_DATA_STREAM
3. Using SET_MESSAGE_INTERVAL

Thanks @rmackay9 for the confirmation. I will hold on a couple days more, as we found a bug that was preventing AP to work correctly on that "point home" action, so next week I will add that and merge this if @julianoes is alright with the changes.

Regarding the default rates, indeed the default behavior changed vs 4.4, but you can change the setting so QGC asks the rates to the autopilot, here:

The difference is that this setting was enabled by default in 4.4, but it is not by default in master.

Is this super problematic for AP? I thought by default in AP we had some kind of default for those SRX parameters. Let me know your thoughts!

@Davidsastresas ok, so we should disable it again in v4.4? PX4 has some default rates. AP requires it to be configured, right?

Hi @Davidsastresas,

Thanks for the feedback on the rates. I think it will be a large problem for AP copter users. Copter does not set the stream rates by default (Plane and Rover do). So if possible I think for AP users QGC should ask for the streams it wants by default

Thanks @DonLakeFlyer, it seems @HTRamsey did the rebase yesterday ( thank you! ) and everything was clear to merge, so I went ahead.

As far as I know, this should leave master with all the features 4.4 currently has. We can follow on that other thread about the default stream rates issue later.

thank you everybody!